?

That'll be the ideal; let's commit and see if anything breaks :D

I also wonder if we should call it global instead of K?

K is typically the convention for this pattern, as it's a generic that represents the property name.

i.e

/**
 * Construct a type with a set of properties K of type T
 */
type Record<K extends keyof any, T> = {
    [P in K]: T;
};

I'm not fussed, but the actual name won't show up much anyway.

It's not really generic though, it's a string. but it doesn't matter like you say 🙂

seems this introduced a type error in normalize

Ah so the proper type should be object, due to:

const mergeGlobalsWithPreset = (
  options: Config.InitialOptions,
  preset: Config.InitialOptions,
) => {
  if (options['globals'] && preset['globals']) {
    for (const p in preset['globals']) {
      options['globals'][p] = {
        ...preset['globals'][p],
        ...options['globals'][p],
      };
    }
  }
};

@SimenB so we've got a couple of options, depending on how you're feeling:

• we stick with any,
• we adjust mergeGlobalsWithPreset to do a typecheck to ensure options['globals'][p] is an object
• we refactor this away: https://github.com/facebook/jest/blob/f47ade4edb112261e14be459185e2396d9c8cbfc/packages/jest-config/src/ValidConfig.ts#L54
• we use a cast or ignore

Looking at the docs, I think any maybe the "correct" type?

A set of global variables that need to be available in all test environments.

For example, the following would create a global __DEV__ variable set to true in all test environments:

Poking around a bit in normalize, I can't actually find what stops jest from crashing with an error about ... ?

Today I learned that you can actually spread a boolean without erroring O.o

To me it looks like the code is broken, and mergeGlobalsWithPreset will discard e.g. the __DEV__: true example from the docs? It should use a proper recursive merge, not blindly spread into one another

Agreed. I'll adjust the implementation.

Ah, finally made it give bad output:

I think unknown is correct, we just need to properly merge the config provided rather than blindly spreading

Yeah for sure - I've got a test and everything; just need to come up with a merging solution.

One of the jest packages already has one coded but not exported - I could move that into jest-utils (iirc that's a package that exists?) a shared package.

Otherwise deepMerge is used by a few packages, so I'll probably just stick that there 🤷‍♂